home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1989 / Jun 89 / V0066-Re Document rethink-Jun89 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.4 KB  |  77 lines  |  [TEXT/GEOL]
  1. Item    9809229                         21-June-89        19:21
  2.  
  3. From:   ROSENSTEIN1                     Rosenstein, Larry
  4.  
  5. To:     D2086                           Efficient Field Svc, C Faith, PRT
  6.  
  7. cc:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    re Document rethinking
  10.  
  11. Curtis,
  12.  
  13. I agree that the application should not know about a document's windows or the
  14. commands to create those windows.
  15.  
  16. You also proposed setting gTarget to the window's document if the window does
  17. not close the document.  This is fine, except that when the next window is
  18. activated it is going to reset the target.  The only place where this is not
  19. true is if that window was the last one on the screen.
  20.  
  21. This gives us the real crux of the problem: you want to have an opened document
  22. without any windows.  (This is what started the discussion originally, I
  23. believe.)
  24.  
  25. Suppose we make this change in MacApp, which I think would be fairly simple.
  26. (Except I think we would have to worry about existing applications that rely on
  27. the current behavior.)
  28.  
  29. One question is whether the application should support multiple documents open
  30. at once.  If it does, then I think you have some serious user interface
  31. problems.
  32.  
  33. How do users choose which document to create the window for?  If there are no
  34. windows opened, then you could have a menu of all the documents, and a check
  35. beside the current document.  (I think this is bad because it is a hidden
  36. mode.)  If there are windows opened, then you have the case where the active
  37. window belongs to one document, but the user wants to create a window belonging
  38. to another document, which seems even more confusing.
  39.  
  40. You could also have a menu that lists all the windows for all the documents,
  41. and then have the user select from than menu. But it sounded like an accounting
  42. application would have 3-4 windows for each document, which would make the menu
  43. unwieldy.  (I am not a fan of hierarchical menus, by the way, and most of the
  44. interface people around here don't like them either.)
  45.  
  46. So I think the only viable interface is to allow the user to open one document
  47. at a time.  I think you could implement this in MacApp by having TApplication
  48. responsible for opening the general data file (ie, the company file in an
  49. accounting program) and having document objects for each kinds of window (ie
  50. Accounts Receivable).
  51.  
  52. A cleaner solution would be to have a special kind of document object that: (1)
  53. allowed the user to have no window opened, and (2) closed itself when the user
  54. wanted to open another document.  This would allow you to have a document with
  55. no windows opened, without comprimising the user interface.  Perhaps this is
  56. really what should be added to MacApp.
  57.  
  58. My preferred alternative is still what I suggested before, which is very
  59. similar to THINK Pascal's project window.  This is a window that represents the
  60. document, from which the user can open windows associated with the document.
  61. (The only change I would make from THINK Pascal is that closing the window
  62. should close the document.)
  63.  
  64.  
  65. Finally, I think there is a difference between an application that is an
  66. general-purpose accounting or database application and an application that
  67. happens to use one of these internally.  Even though an application might use a
  68. database internally, it may present an entirely different model to the user.
  69. (I am not sure that these account for 1/2 of all MacApp development, at least
  70. based on the programs that are currently shipping.)
  71.  
  72.  
  73. Larry
  74.  
  75.  
  76.  
  77.